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. Titel: Verfahren zum Debu.ggen rekonf igurierbarer 

' * Architekturen ' ' . 

*. 5 . Beschreibung 

Die vorliegende Erf indung bef afit sich mit Verfahren fiir das 
Debuggeh. vori Programmen auf .konf igurierbaren Architekturen. 
Unter einer rekonf igurierbaren Architektur • werden u, a. Bau~ 
10 steine (VPU). mit konf igurierbarer Funktion und/oder Vernet- 

•zung verstanden, insbesondere integrierte Bausteine mit einer 
Mehrzahl von ein-' oder mehrdimensional angeordneten arithme- 
tischen und/oder logischen unjd/oder analogen und/oder spei- 
chernden und/oder- vernetzeriden Baugruppen (im Foigenden PAEs 
. 15 • genarint), und/oder kommunikativen/peripheren Baugruppen . (lO) , 
die direkt Oder durch- ein oder mehrere Bussystem(e) miteinan- 
der. verbunden . sind. PAEs'sind in beliebiger Ausgestaltung, 
Mischung und Hierarchie angeordnet- Diese Anordnung wird im 
weiteren PAE-Array oder PA genannt. 

20 

Zur Gattung diesier Bausteine zShlen systolische Arrays, neu- 
ronale Netze, Mehrprozessor-Systeme, Prozessbren mit mehreren 
Rechehwerken und/oder logischen. Zellen, Vernetzungs- und 
Netzwerkbausteine wie z.B. Crossbar-Schalter , ebenso wie be- 
25 kannte Bausteine der Gattung FPGA, DPGA, XPUTER, etc: Hinge- 
wiesen wird insbesondere in diesem Zusammenhang auf die fol- 
genden Schutzrechte desselben Anmelders : P 44 16 881.0-53, DE 
197 81 412.3, DE 197 81 483.2, DE 196 54 846;.2-53,' 
DE 196 54 ^593.5-53, DE 197 04 044.6-53, DE- 198 80 129.7, 
30 DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 0.0/01869, 
DE 100 36 627.9-33, DE 100 28 397.7, DE 101 10.530.4, ' 
DE 101 11 014.6, PCT/EP 00/10516, EP 01 102 674.7, 
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• 2. . . '• . 

DE 102 06 856.9, 60/317,876, DE 102.02 044.2, .DE 101 29 
237,6-53, DE 101 39 170. 6. Diesesind hiermit zu Of f enba- • 
rungs zwecken .vollumfanglich eingegliedert. • . . 

5 Weiterhir^ soil ahgemerkt werden, dafl die zu beschreibenden . 
Verfahren auch auf Gruppen von mehreren Bausteinen angewendet 
werden konneri. Dennoch wird nachfolgend auf VPU und/oder auf 
„Bausteine'^ Bezug genommenL Diese Bauteile und der^n Betrieb ' 
sind- noch zu verbessern. ' 
10 . • , 

Die Auf gabe der vbrliegenden Erf indung besteht darin, Neues 
ftir die gewerbliche Anwendung bereitzustellen. " 

Die LOsung der Auf gabe wird una'bhangig beansprucht. Bevorzug- 
15 te Ausfuhrungsformen befinden sich in den Unteransprtichen. 

1 . Erf indungsgemaSes Verfahren 

20 Es warden nachfolgend mehrere Verfahren und Hardwareimplemen- 
tierungen vorgestellt, die ein ef fizientes Debuggen von VPU- • 
Systemen ermoglichen. 

Das Debuggen erf olgt in'einer bevorzugten Vafiante entweder 
25 durch die Verwendung eines entsprechend an eine VPU Oder den 
Baustein angeschlossenen Microcontrollers oder durch eine 
. Ladelogik nach den Patenten P 44*16 881.0-53, 
DE 196 51 075.9-53,. DE 196 54. 846.2-53, DE 196 54 593.5-53, 
DE 197 57 200.6-33, DE 198 07 872.2, DE 101 39 170.6, ' - 
30 DE 199 26 538.0, DE 100 28 397.7, die durch Bezugn^hme 

vollumfanglich eingegliedert sind. Wie ersichtlich sein wird, 
sind aber auchandere Hardware-Variant en verwendbar. 
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Folgende grundlegende Verf ahren sollen " alternativ und/oder 
■gemeinsam dabei angewendet werden: 

1.1 Erkexmen elner Debug-Bedxngung 

1.1.1 Bedirtgunq . * . • * 

Durch den Prograitimierer. wird beispielsweise • innerhalb des De- 
bug-Tools eine dder rfiehrere Bedingungen festgelegt, die das 
Debugging starten (vgl. Breakpoint nach dem Stand der Tech- 
nik) . Das Auftreten der Bedingungen wird zur Lauf zeit in der. 
VPU und/oder exnem beliebigen mit- der VPU datenaustauschenden 
Gerat festgestellt. Dies geschieht beispielsweise durch das 
Auftreten von bestimmten Datenwerten hex bestimmten Variablen 
und/oder bestiiratitfen Triggerwerten bei bestimmten PAEs. 

1.1.2 Vprbedinqung * 

Im Optimalfall kann eine bestiininte Bedingung gemali o.g. Defi- 
nition bereits mehrere. Takte vor dem Eintref fen der Debug- 
Bedingung durch den Programmierer festgelegt werden. Dadurch 
werden bestimmte Latenz-Probleme^ die im folgende^ diskutiert^ 
werden, von vornherein ausgeschlossen. • 

Es sollen im folgenden zwei grundlegende Arten des Debuggings 
fur VPUs diskutiert werden, wobei die jeweils bevorzugt anzu- 
wendende Methodevon der Wahl des Compilers abhangt: ' 
Far Compiler*, die Code auf Basis von instantiierten Modulen 
einer Hardwarebeschreibungssprache (oder ahnlichen Sprache) 
generieren, kann sich besonders die im folgenden beschriebene 
Methode- A eignen*. 
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Ftir Compiler .ahnlich DE 101 39 170,6 und Zusatzanmeldungen, 
die komplexe .Instruktionen erzeugen und nach einem VLIW- . 
ahnlichen Vdrfahren geherieren, eignet sich besonders die im 
folgenden beschriebene Methode B. Grundsat zilch ist fur den 
5 'Betrieb einer VPU'oder eines entsprechenden Bausteins als 
Prozessor od.er Coprozessor Methode B die bevorzugt anzuwen- 
dende. ' * • , • 

Es wurde erkannt, dass insbesondere die Verwendung beider Me- 
10 thode^n A und gemeinsam zu den besten und tirahsparentesten 
Debuggingergebnissen ;ftahrt, Insbesondere kann je nach Tiefe 
des zu debuggenden Fehlers zunachst unter Zuhilf enahme der 
schnellen Debuggingmethode B debuggt werden und nach hinrei- 
chende Lokalisierung des Fehlers sodann per Methode A die De- 
15 tails in der "Tiefe" analysiert werden . 

2. Nfethode A 

20 2.1 Grundprinzxp 

Nach dem Auftfeten einer (Vor) Bedingung wird die VPU angehal— 
ten. Danach werden die relevanten Debug-Inf ormationen aus den 
PAEs an das .Debug-Programm tibertragen. Die relevanten Debug- 
Inf ormationen wurden z.uvor durch den Prograirimierer . innerhalb 
25 des Debug-Programmes festgelegt. Nach Auslesen aller relevan.- 
ter Debug-Infoririationen wird der nachste Takt • ausgef uhrt und 
erneut die relevanten Debiig-Inf ormationen .ausgelesen. Dies 
Wiederholt sich solange^ bis der Programmierer den Debug- 
Vorgang abbricht . Ahstelle des Anhaltens der VPU sind eventu-' 
30 ell andere Verfahren denkbar. So kOnnen fur eine gegebene Ab- • 
folge von Takten wiederholt ^Daten zum Auslesen bereitgestellt 
werden, sofern dies s'chnell genug mSglich ist'. 
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2.2 Uzi'bers-bii'kzung durch di^ Hardware. 

2.2.1 Auslesen der Register 

Wesentlich fur die Funktionsweise des Debuggers ist die Mog- 
lichkeit, durch eine iibergeofdnete Einheit (im folgenden De- 
bugProzesso'r (DB) genannt) , also beispielsweise eine CT oder - 
Ladelogik, einen anderen extern angeschlossenen (Host)Pro- 
zessor.oder einen reservierten Arraybereich, die internen Da-: 
tenregister und/oder Statusregister und/oder Zustandsregister 
und ggf . je nach Implementierung weitere relevante Register, 
und/oder Signale aus den PAEs und/oder dem Netzwerk zurackzu- 
lesen bzw- dies nur fiir ausgewahlte Register bzw. Signale zu 
tun (zusammengefaJit im folgenden als Debuginf ormation .be- 
zeichnet) . Eine derartige Moglichkeit ist z. B,. mit der in 
der PCT/DE 98/00334 geschaf f enen 'Verbindung zwischen der 
Ladelogik und dem Datenbus einer PAE (PCT/DE 98/00334 0403, 
Fig. 4) realisierbar- 

Es soli ausdrucklich angemerkt sein, dali auch serielle Ver- • 
fahren zum Auslesen der Register verwendet werden konnen.- 
Beispielsweise kann JTAG gewahlt werden und der DB uber die- 
ses 'Verfahren ggf. auch als externes seperates und evtl.- auch 
marktubllches Gerat (z. B. Firma .Hdtex, Karlsruhe) ange- 
schlossen seiri. 

Da bevorzugt auf sSmtliche. Register, oder zumindest eine- er- 
heblich Anzahl derer,. durch den Debugger schreibend urid/oder . 
lesend zugegriffen werden kann, kann optional und bevorzugt 
ein wesentlicher Teil der (seriellen) Verkettung der Register 
zu Testzwecken (Scan-Chain) ftir die Produktionstests des ^ ' 
Chips entf alien. Die Scan-Chain wird normalerweise daftir ver- 
wendet, uin alle Register innerhalb eines Chips wahrend der 
Produktionstests mit Testdaten vorladen, zu konnen und/oder 
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die Inhalte der Register zu Testzwecken wieder zuruckzulesen. 
■Das Vorladen' und/oder Zurticklesen geschieht dabei typiacher- 
weise durch Testsysteme (z.B, SZ Testsysteme, Aiuerang) 
urld/oder gemali den in der DE 197 57 200.6-33 beschriebenen 
Ve.rfahren. Die Scan-Chain benotigt dazu einen zusatzlichen 
nicht unerheblichen Hardware- und Flachenauf wand fur jedes 
Register. Dieser kann nunmehr, zumindest fur die Register, 
die debugbar sind, ehtfallen,. wenn - wie erf indungsgemali vor- 
geschlagen -.die Produktionstestanlageh aber geeignete 
Schnittstellen (z,B. parallel/ seriell, JTAG, etc.) Zugrif f . 
auf die Register erhalten. 

2.2.2 Anhalten oder Verlangsamen des Taktes 

Durch das Auftreten von Bedingung und/oder Vorbedingung kann 
der Takt entweder angehalten oder verlangsamt werden, um hin- 
reichend Zeit zum Auslesen zur Verftigung zu stellen. Ausge- 
lost wird dieser Debugbegihn insbesondere entweder direkt 
durch eine PAEy die. die (Vor) Bedingung (en) berechnete oder 
durch eine ubergeordnete Einheit (z. B. Ladelogik/CT, Host- 
prozessor) aufgrund beliebiger Aktionen, beispielsweise durch 
die Information, daB an einer PAE eine (Vor ) Bedingung auftrat 
und/oder durch eine Aktion innerhalb des DebugProzessors 
und/oder durch ' ein beliebiges Prograiran und/oder eine beliebi- 
ge externe/periphere Quelle. Zum Informieren stehen Trigger- 
mechanismen entsprechend P 44 16 881.0-53, DE 196 51 075.9-^ 
53,, DE 197 04 728..9, DE 198 07 872.2, DE. 198 09 640.2, DE 100 
28 397.7 zur Verfugung. Alternativ kann b^im Debuggen der 
Takt generell verlangsamt werden. Solien nur Arrayteile de- 
buggt werden, kann eine partielle Heruntertaktung vorgesehen 
werden. 
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Sofern der Takt verlangsamt wird, muss durch den Debugprozes- ' 
sor innerhalb .des verlangsamten . Zyklus des Verarbeitungstak- • 
tes alle relevante . Debug-Inf ormation aus den PAEs ausgelesen 
werden- Dazu ist es sinnvoll und bevorzugt, den Takt nur par-, 
tiell zu .verlangsamen,. also den Arbeitstakt zu senken Oder 
anzuhalten, .aber den Takt fur den Aus lesemechani sinus weiter 
fortzufahren. Des weiteren ist es sinnvoll und bevorzugt, ge- 
nerell.die Register zum Datenerhalt mit Takt zu versorgen. 

Nach dem Anhalten des Taktes kann ein Single-Step Modus rea- 
lisiert werden, d-h. der Debugprozessor ha'lt den Verarbei- 
tungst^kt so lange an, bis er alle Debug- Information* ausgele- 
sen hat. Danach startet er den Verarbeitungstakt wieder ftlr 
einen Zyklus und halt ihn erneut bis nach dem Auslesen- aller 
relevanten Debug-Inf ormationen an. 

Der Auslesetakt und der Takt des Debug-Prozessors sind bevor- i 
zugt unabhangig vom Verarbeitungstakt der PAEs, so dali die 
Dateriverarbeitung vom Debugging und insbesondere Auslesen der 
Debug-information getrennt ist. 

Hardwaretechnisch wird das Anhalten oder Veriangsamen des 
Taktes durch Methoden nach dem Stand der Technik, wie bei- 
spielsweise Gated-Clocks und/oder PLLs und/oder Teller oder 
andere Verfahren er^reicht. Diese Mittel werden bevorzugt an 
geeigneten Steilen (Knoteh) innerhalb des Clock-Trees einge- 
fugt, so dafi eine globale^ Taktsteuerungen der jeweils tiefer- 
liegenden Zweige realisierbar ist. Die Heruntertaktung nur 
von ausgewahlten Array teilen ist in den unter Bezug genomme- 
nen Anmeldungen des vorliegenden Anmelders offenbart-. * 

Besonders bevorzugt ist das Versenden einer Taktsteuer- 
Information von einer libergeordneten Einheit (z.B. Ladelo- 



PCT/DE 02 / 03 27 S 



gik/CT,- Hostprozessor) an samtliche bzw. samtliche zu debug- 
genden PAEs . Dies kann bevorzugt tiber das Konf igurationsbus- 
system erfolgen. Die Taktsteuerinf ormation wird dabei typi- 
scherweise gebroadcastet ub^rtragen, d.h. alle PAEs erhalten 
5 dieselbe Information. 

Beispielsweise konnen. folgende Taktsteuerinf ormationen imple- 
mentiert sein: 

10 STOP: Der Arbeit stakt wird angehalten. 

SLOW: Der Arbeitstakt wird verlangsaint • 

STEP: Exakt ein Verarbeitungsschritt (Single Step Modus) 

wird ausgefuhrt und dann der Arbeitstakt wieder an- 
gehalten. . ■ • 
15 STEP(nJ: n Verarbeitungsschritte werden ausgefuhrt und darin 
der Arbeitstakt wieder angehalten. 
GO: Der Arbeitstakt lauft normal weiter. 

E^ soil insbesondere erwahnt sein, dass das Verfahren der 
20 Taktabschaltung und/oder Verlangsamung ebenso eingesetzt wer- 
den kann,. um den Stromverbrauch zu reduzieren.- Sofern tempo- 
rSr keine Rechenleistung ben5tigt ' wird, kann ein "Sleepmode" 
beispielsweise durch das Abschalten des Arbeitstaktes (STOP) 
Oder durch spezielle Befehle (SLEEP) realisiert werden. Wird 
25 riicht die voile Rechenleistung benotigt, kann der Takt durch 
die Verwendung von SLOW verlangsamt werden und/oder temporar 
durch STEP (n) ausgesetzt werden. Insoweit ist das Verfahre.n 
optional und/oder zusStzlich zu den in der DE 102 06 653-1 
beschriebenen Verfahren zur Reduzierung der Verlustleistung 
30 einsetzbar. . * • 



Ein Problem des Broadcastings von Taktsteuerinf ormationen ist 
die Obertragungszeit des Broadcastes durch das Array aus 
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^PAEs. Die Ubertragung kann bei hoheren Taktf requenzen nicht 
innerhalb eines Arbeitstaktes erfolgen. Es ist aiber zwingend 
notwendig, dass samtliche PAEs zur gleichen Zeit auf die . • 
Taktsteuerinfoinmationen reagieren. Bevorzugt wird die Takt- 
5 steuerinformation dahef Ober ein gepipelintes Bussystem Shn- 
■ lich des in DE 100 28 397.7 beschriebenen CT-Bussystems Uber- 
tragen. Weiterhin wird eifl' Zahlenwert (LATVAL) den Taktsteue- 
rinf ormationen hinzugefugt der'gleich oder grOBer der maxima- 
len Lange der Pipeline des Bussystems ist. In jeder Pipeli- 
10 nestufe wird taktweise der Zahlenwert dekrementiert (Subtrak^ 
tion von 1) . Jede PAE, die die Takt steuerinformation erhSlt, 
dekrementiert im weiteren den Zahlenwert mit jedem Takt. Da- 
mit ist sichergestellt, dass der Zahlenwert in dem gepipelin- 
.ten Bussystem und den PAEs, die die Takt steuerinformation be- 
15 reits. empfangen haben, immer exakt gleich ist. Erreicht der 

Zahlenwert den Wert. 0, 'ist sichergestellt , dafi alle PAEs die , 
Taktsteuerinformation erhalten haben. Jetzt tritt die Takt-- 
steuerinformation in Kraft und das Verhalten des Taktes wird 
entsprechend inodif iziert . 
20 . * 

1 Durch das- beschriebene Verf ahren entsteht eine weitere La- 
tenzzeit (Latency). Diese kann beispielsweise durch die nach- 
folgend beschriebene- Registerpipellne zusStzlich abgefangen 
werden^ oder, wie besondeps bevorzugt, durch dife Definition 
25 .der (Vor) Bedingung abgefangen werden, indem die(Vor)Be- 
dingung soweit vorgesetzt wird, daJi die Latenzzeit bereits 
berticksichtigt ist. 

Es soli besonders ..erwahnt werden, dafi . die Latenzzeit im Sin- 
30 gle-Step Modus vernachlassigbar ist, da sie nur bei der Ab- 
schaltung es Taktes. (STOP) eine Rolle' spielt. Da de.r Befehl 
STEP immer nur exakt einen Schritt ausftihrt, kommt es wahrend 
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des Single-rStep Betriebes durch keinerlei Verfaischung (Ver- 
zogerung) der Debugdaten durch die Latenzzeit. 

5 2 .-2, 3 Registerpipeline zum Ausgleichen der Latency 

Bei hoheren Betriebsf requenzen. kann as zu einer Latenzzeit 
• zwischfen dem Erkennen des Debugbeginns uhd dem Anhalten .oder 
Verlangsamen des Taktes koramen. Diese Latenzzeit ist exafct 
vorherbestiininbar, da die Position der .verzogemden Register 
10 . in der VPU durch Hardware und/oder den zu debuggenden Algo- 
rithmus definiert und durch den Debugger daher exakt bere- 
chenbar ist. 

Durch die Latenzzeit verschieben si.ch jedoch die dem Debug- 
15 Prozessor zur Vefftlgung gestellten Inf orma-tionen derart, dafl 
nicht mehr die korrekten Debuginf ormationen ausgelesen werden . 
kSnnen. Bevorzugt wird dies durch ein entsprechendes Festle- 
gen der (Vor) Bedingung durch den Programmierer gelost.' Optio- 
nal kann durch das Einfiigen einer mehrstuf igen Registerpipe- 
. .20 line, die die Debuginf ormation in jedem Takt um ein Register . - 
welter iibertragt, der Debugprozessor aiuf so yiele Takte an 

• Debuginf ormationen zuriickgreif en, w.ie die Registerpipeline 
lang ist. Die Lange der Registerpipeline ist so auszulegen^ 
dali sie der maximal zu erwartehden Latenz eritspricht. Auf- 
25 grund der exakteh Berechenbarkeit der Latenzzeit ist esnun- 
mehr dem Debug- E?rograinm moglich, die zeitlich. korrekte, rele- 
vante Debug-Inf ormation aus der Registerpipeline auszulesen. 

Eixi ^auf tretendes Problem bei der Verwendung von Registerpipe- 
3b lines ist, dafl diese- verhaltnismaflig lang und damit, bezpgen 
auf die' fiir die Realisierung notwendige Siliziumf lache, teuer . 
sind. 

. ^ • - 



I 
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. • . yi^ 

2.3 Slchtbare Debug- Infoxma-bxonen i . 

. Bei dieser . Methode wird im wesentlichen nach Auftreten der 
5 (Vor) Bedingung ' debugt , da erst danach der Takt verlangsamt 
Oder angehalten wird urid das Auslesen der Debug-Inf ormation 
' erfblgt. Debug-Inf oimationen, die vor dem Auftreten der 
(Vor) Bedingung liegen/ sirid daher zunachst rpiicht sichtbar. 

10- Es ist jedoch, wenngleich auch.unter Verlust an Arbeitslei- 
^ stung, moglich- eine VPU sofoirt vom Start einer Applikation an 
W mit verlangsamten Takt oder Single-Step-Modus zu. betreiben. 

Vom Start an warden die relevanten Debug-Inf ormationen vom 

Debug-Prozessor ausgelesen ; ' 
15 ■ • • . 

3. ^thode B 

3 . 1 Grundprinzip 

20 ' ' 

Relevante Debug-Inf ormationen aus den Speichereinheiten, die 

^ gemaii P 44 16 881.0-53, DE 196 54 846.2-53, DE 199:26 538.0, 

m DE 101 39 170.6 und deren Zusat zanmeldungen, DE 101 10 530.4 
die Anwendungsdaten- und Zustande eines best immten. Arbeit s- 

25 schrittes beinhalten, werden. an das Debug- Programm libertra- 
gen. Diese Speichereinheiten, nachfolgend auch- Arbeitsspei- 
* Cher genannt, arbeiten im Maschinenmodell nach- der P 44 16'. 
881.0-53, DE 196 54 846.2-53, DE 101 39 170.6. und deren Zu- 
satzanmelduhgen, DE 199 26 538.0, DE 101 10 530.4 quasi als 

30 .Register zur * Speicherung von Daten, di^ innerhalb eines Kon- 
figurationszyklusfes im PA oder Teilen .des PAs berechnet wur- 
den. Es wird insbesondere auf die Patentanmeldung DE 101 39 
170.6 und deren Zusat zanmeldungen verwiesen, in der die Ver- 
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wendung der Speichereinheiten als Register (REG) zur'Reali- 
sierung eines Prozessormodells detailliert beschrieben ist,. 
Die DE 101 39 170.6 und deren • Zusatzanmeldungen sind zu Of- 
f enbarungszwecken vollumf anglich eingegliedert . Eine Spei- 
5 chereinheit besteht dabei aus einer beliebigen Anordnung und 
Hierarchie von unabhangigen und abhangigen Speichern. Es ist' 
mCglich, gleichzeitig mehrere unterschiedliche Algorithmen 
auf dem PA (Processing Array) auszufiihren, die dann unter- 
schiedliche Speicher verweriden, 
10 • . . 

Wesentlich far die Ahwendung dieser Methode ist, dali Daten 
und/oder algorithmisch releva!nte ZustSnde in die den PAEs zu- 
geordneten Speichereinheiten abgelegt sind, wobei eine Spei- 
chereinheit jeweils zumindest derart dimensioniert ist, dafi 
15 alle relevanten . Daten und/oder Zustande eines Zyklus ge.spei- 
chert warden k5nnen; hierbei kann die Lange eines Zyklus 
durch die Grolie der Speichereinheit bestimmt sein und ist es 
bevorzugt auch (vgl. DE 196 54 846.2-53). Mit anderen Worten 
wird die Zykluslange der Hardware angepaJBt. 
20 . 

Unterschiedliche Oaten und/oder Zustande warden derart in die" 
Speichereinheiten gespeichert, daU diese aindeutig dam Algo- 
rithraus zugeordnet werden konnen. Dadurch kann der Debugger 
die relevanten Daten und/oder Zustande (Debug-Inf ontiation) 
25 eindeutig identifizieren. 

Die relevanten Debug-Inf ormationen kOnnen - insbesondere auch 
vorab - durch den Progranunierer innerhalb des Debug-Pro- 
grammes festgelegt werden. Diese Debug-Inf ormationen werden 
30 aus den Speichereinheiten ausgelesen, Dazu stehen unter- 
schiedliche Methoden zur .Verfiigung; einige Moglichkeiten wer- 
den nachfolgend naher beschrieben." Nach dem Auslesen aller 
' relevanter Debug-Inf ormationen wird der nachste Konfigurati- - 
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10 



yl3 



onszyklus ausgefiihrt und erneut' die relevanten Debug-Infor- 
mationen ausgelesen- Dies wiederholt sich so lange> bis der 
programmierer/ Debugger den Debug-Vorgang abbricht. 

Mit anderen Worten werden die relevanten Daten und/oder Sta- 
tusinf ormationen nicht - taktweise, sondern konf igurationsweise 
an den Debugger tibertragen.. Dies geschieht aus den Spei- 
chereinheiten, die mit den Registern einer CPU vergleichbar 
sind. y" 



3 . 2 nn-bers-bu-bziuig durch die Hardware 

Wesentlich ftir die Funktionsweise des Debuggers ist die M5g- 
15 lichkeit, durch die CT oder einen anderen extern angeschlos- 
senen Prozessor {im Folgenden >'DebugProzessor (DB) genannt) , 
die beispielsweise auch interne (n) Arbeitsspeicher der VPU zu 
lesen. Eine derartige Mogliclrjkeit ist z.B. durch den Anschlufi 
der CT an die Arbeitsspeicher zum Vorladen und Lesen der Da-' 
20 ten und/oder durch die in der DE 199 26 538.0 beschriebene 

Verfahren ziim Herausschreiben der internen Speicher an exter- 
ne Speicher gegeben. In einer mogliche Ausgestalturig kann auf 
Arbeitsspeicher durch versohieden Verfahren nach dem Stand 
der Technik (z,B, Shared Memory ^ Bank Switching) derart vom 
25 DebugProzessor. zugegriffen werden, dass- der Datenaustausch 

mit dem DB. weitQStgehend unabhSngig von einer weiteren Daten- 
verarbeitung in der VPU erfolgen kan!n. 

In einer moglichen Ausgestalturig kann z. B. entsprechetid Me- 
30 thode A durch eine oder mehrere .der vorstehend beschriebenen 
Mafinahmen der Takt der VPU zum Auslesen der Speicher gegebe- 
nenf alls \entweder entsprechend verlangsamt oder angehalten 
werden und/oder gegebenenf alls im Single-Step-Modus betrieben 
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werden. Dabei kann je nach Implementieriing der Arbeitsspei- • 
cher, z. B. beim Bank-Switch-Verf ahren, auf einen besonderen 
Eingriff in den Takt verzichtet werden. Typischerweise ge- 
schieht das Anhalten oder Verlangsamen des Taktes nach Metho- 
de B und das Auslesen und/oder Kopieren .und/oder Umschalten 
der Arbeitsspeicher nur, wenn ein Datenverarbeitungszyklus 
bzw. Konf igurationszyklus beendet ist. 

. Mit anderen Worten ist ein wesentlicher Vorteil von Methode 

B, dass keine besondere Unterstutziing durch die Hardware er- 
. forderlich. isti 

In einer m5glichen Ausgestaltung muB ein DB. lediglich Zugriff 
auf die Arbeitsspeicher besitzen. In einer besonders zu be- 
vorzugenden Ausgestaltung geschieht der Zugriff ,auf die Ar- 
beitsspeicher durch eine geeignete Konf iguration der VPU^ die 
dadurch die Arbeitsspeicher selbstandig und ohne Modifikation 
ausliest und an einen DB Qbertragt. . " 

3.3 Zugiriff auf Debug- Infoimatxon 

In der P. 44 16 881.0-53, DE 196 54 846.2-53, DE .101 39 170.6, 
DE 199 26 538.0 sind Dateriverarbeitungsverf ahren- beschrieben, 
bei denen zyklisch eine Menge an Operationen auf einen' rekon- 
f igurierbaren Datenverarbeitungsbaustein "abgebildet werden. 
In jedem Zyklus wird eine Mehrzahl von Daten berechnet, * die 
von einer peripheren Quelle und/oder . einen internen/externen 
Arbeitsspeicher stammen und an eine periphere Quelle und/oder 
einen internen/externen; Arbeitsspeicher geschrieben werden. 
Dabei konnenv jeweils unterschiedliche und/oder vor allem meh- 
rere unabhangige Arbeitsspeicher gleich^eitig verwendet wer-: 
den J Beispielsweise konnen in diesem Datenverarbeitungsver- ' 
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fahren die Ar.beitsspeicher ' Oder ein Teil der, Arbeit sspeicher 
als Registersatz dienen. 

Nach der DE 101 39 170/6 und der DE 199 26 538-0 warden dabei 
samtliche Daten und Zust'ande, die fiir die weitere Datenverar^ 
beitung relevant sind, , in die Arbeitsspeicher abgelegt 
und/oder aus selbigen gelesen. In einem bevorzugten Verfahreh 
werden fiir die .weitere Datenverarbeitung irrelevante ZuStande 
nicht gespeichert. 

Die Unterscheidung zwischen relevanten und irrelevanteri Zu- 
standen soil an folgendem Beispiel aufgezeigt werden, es soil \ 
zu Of f enbarungszwecken dabei insbesbndere auf die Ausfiihrun- 
gen in der DE 101 39 170.6 verwiesen werden: 

Die Zustandsinf ormation eines Vergleichs ist beispielsweise 
ftir die weitere Verarbeitung der Daten wesentlich, da dieser 
die auszufahrenden Funktionen bestimmt. ' 

Ein sequerizieller Dividierer entsteht beispielsweise durch 
Abbildung eines Divisionsbef ehles auf eine Hardware, die nur 
die' sequenzielle Division unterstutzt- Dadurch entsteht ein 
Zu3tand, der den Rechenschritt innerhalb der Division kenn— ■ 
zeichnet. Dieser Z.ust^nd ist irrelevant, da fur den . Algorith- . 
mus nur das Ergebnis (also die- ausgeftlhrte Division) erfor- 
•derlich ist . In diesem Fall werden also' lediglich das Ergeb- 
nip und die Zeitinf ormation (also die Verf ugbarkeit) benO- . 
tigt. - - . . 

Die Zeitinf ormation ist .beispielsweise ' in der VPU-Technologie 
nach P 44 16 881.0-53, DE 196 51 075.9-53, I?E 199 26 538.0 
durch das RDY/ACK Handshake erhaltflich. Hierzu ist jedpch be- 
sonders. anzumerken, dafi das Handshake ebenfalls keinen rele- 
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vanten Zustand- darstellt, da. es . lediglich die GQltigkeit der 
Datien signalisiert, wodurch sich' wiederum die verbleibende 
relevate Information auf die Existenz giiltiger Daten redu- 
ziert. ' , 

' 5' 

In der DE 101 39 170.6 wird eine Unterscheidung zwischeh lo- 
kal und global relevanten Zustand.en aufgezeigt: . * 

* lokal: Der Zustand ist nur innethalb einer einzigen abge- 
10 schlossenen Konf iguration relevant Daher muB der Zustand 
nicht zwingend gespeichert werden. 

global: Die Zustandsinf ormation wird ftir mehrere Konfigura- . 
tionen benOtigt. Der ■ Zustand itiufi gespeichert werden • 

15 Es ist nunmehr denkbar, dalJ der Programmierer einen lokal re- 
levanten Zustand debuggen will, der nicht in den Speichern 
abgelegt ist. In diesem Fall kann die Applikation dahirigehend 
mbdifiziert werdeh,. dafi eine Debug-Konf iguration entsteht 
(aquivalent zum Debug-Code von Prozessoren) , die eine Modifi- 
20 kation zum "normalen" Code der Applikation derart aufwei^t, 

daJ5 dieser Zustand zusatzlich in die Speichereinheit ge- . 
schrieben und damit. dem Debugger zur Verfugung gestellt wird. 
Dadurch entsteht eine Abweichung zwischen Debug-Code und tat- 
sachlichem Code, die zu einem unt'erschiedlichen Verhalten der 
25 Codes f ahren kann. 

In e.iner daher besonders bevorzugten Ausfiihrung wird keine 
Debug-Konf iguration verwendet.. Vielmehr wird • die 'z\i debuggen- 
de Konf iguration derart terminiert, dass die fiir Debugging- 
30 zwecke zusatzlich erf orderlichen Daten die Terminierung aber- 
dauern, d.h. weiterhin gtiltig in den entsprechenden Speicher- 
steilen (REG) .(z.B. Register, Zahler, Speicher) verbleiben. 
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Wenn die zu debuggende Konf iguration derart tentiiniert wird, 
■ dafi die fiir Debugging-Zwecke zusatzlich erf orderlichen Daten 
die Terminierung uberdauern, ist es moglich, ein Debuggen 
einfach dadurcph durchzuf iihren, dafi nicht die nachste, bei' 
S normalem Programmablauf erf orderliche Konf iguration geladen 

wird^ sondern stattdes:sen eine Konf iguration;. uber welche die • 
• < . zu den Debugging- Zwecken erfprderlichen Daten in die Debug- 
Einheit bzw, das Debug-Mittel' abertragen werden, Es sei dar- 
auf hingewiesen, dafi. bei einem solchen Debuggen auch iia spS- 
10 teren Ablauf des Programmes stets die zu Debug-Zwecken' erfor- 

• derlichen Daten mit abgespeichert .werden* konnen, wodurch' si- 
chergestellt ist^ daB das spSter ausgeftlhrte Programm in ex- 
akt der Weise einem Debug-ProzelS unterworfen wurde wie erfor- 
derlich. Nach Auslesen der Debug-Inf ormation durch eine dedi- 
15 zierte Debug-Konf iguration kanri dann mit der normalen Pro- 
grammausf iihrung fortgefahren werden. 

Eine Konf iguration wird geladen diese verbindet die REG in 
geeigneter. Weise und definierter Reihenfolge mit einem oder 
mehreren globalen Speicher(n), auf die der DB. Zugriff hat 
(z-B.. Arbeit sspeicher) . 

Vorgeschlagen wird also, dafi eine Konf iguration geladen wird, 
diese die REG in geeigneter Weise verbindet und in definier- 
ter Reihenfolge ,mit einem oder mehreren globalen Speichern 
verbindet, auf die der DB Zugriff hat'(z. b/ Arbeitsspei- • 
cher) . • 

Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
wenden, um auf den/die globalen Speicher zuzugreifen. Die 
Konf iguration kann' beispielsweise Adressgeneratoren verwen- 
den, um auf als- Speicher ausgestaltete REG zuzugreifen. Ent- 
sprechend der. konf igurierten Verbindurig zwischen den REG wer- 
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den die Inhalte der REG in einer definierten Reihenfolge in 
den globalen Speicher geschrieben, .wobei die jeweiligen 
Adressen von Adressgeneratoren vorgegeben werden. Der Adress- ■ 
^generator generiert die Adressen fur den/die globalen Spei- 
cher(n) derart, dalJ die. beschriebenpn Speicherbereiche (DEBU- 
GINFO.) der entfernten zu debuggenden Konf iguration eindeutig 
zugeordnet werden konnen. 

Das Verfahren entspricht dem Koritext-Switch in DE 102 06 
653.1 und DE 101 39 170.6, die zu Of f enbarungszwecken vollum- 
fanglich eingegliedert sind. , ^ . 

Der DB -kann nunmehr auf die Daten innerhalb eines ihm zugang- . 
lichen Speicherbereiches (DEBUGINFO) zugreifen.' Soli das De- 
bugging mittels eines Single-Step Verfahrens durchgefuhrt 
werden, kann nach jedem single step einer zu debuggenden Kon- 
f iguration ein. Kontext-Switch derart . durchgefuhrt werden, 
dass samtliche Daten erhalten bleiben und die.zu debuggende 
Information aus den REG in einen, Arbeitsspeicher geschrieben 
wird. Sodann wird wiederum unter Erhalt der Daten die zu de- 
buggende Konf iguration wieder konfiguriert und fur einen wei-- 
teren single step ausgef uhrt . . Dies geschieht fUr jeden zu de- 
buggenden single step der zii debuggenden Konf iguration. Auf 
die MSglichkeit eines Debugging unter Verwendung der als „Wa- 
ve-Rekonf iguration^^ bekannten Prinzipien sei' hingewiesen. 

3 . 4 Slchtbare Debug- Infonoatlonen 

Ein Debuggen vor der (Vor) Bedingung kann vergleichsweise ein- 
fach und ohne groBe Perf ontiance-Verluste durchgefuhrt werden, 
da die benotigte'n Debug-Inf ormationen in Arbeitsspeichern 
verfugbar sirid. Durch das Obertragen der Arbeitsspeicher in 



rer/PE 0 2 / 0 3 27 8 



10 



/iS . 

andere Speicherbereiche, auf die der DB bevorzugt direkten 
Zugriff hat, kann die Debug-Inf ormation einfach sicherge- 
stellt werden. Elne noch schnellere Methode ist, die Arbeits- 
speicher durch ein..Bank-Switching-Verf ahren. (nach dem Stand 
der Technik) derart ,zwischen den einzelnen Konf igurationen 
umzuschalten, daB die Debug-Inf ormation in einer jeweils neu- 
en Bank liegt. .Das Umschalten kanri -sehr zeitoptimierend, im 
Optimalfall sogar ohne Auswirkung auf die V.erarbeitungslei- 
stung erfolgen. 



Es ist bereits offenbart worden, daB bei einer VPU Daten* i 
'blockweise in einen Speicherbereich Ubertragen werden kbnnen. 
Dieser kann auch atiBerhalb des eigent lichen PA .liegen 
und/oder einen" Dual- Port ed-RAM oder dergleichen aufweisen, so 
15 daB es moglich ist, auf die eingeschriebene Information von 
auBen leicht zuzugreifen. 



4 , Funktionsweise des Debuggers 



20 



Das Debugger-Programm selbst kann auf einem DB aulierhalb des 
PAs ablaufen. Alternatiy dazu kann eine VPU selbst den DB 
darstellen, entsprechend" der Methoden, die bei Prozessoren 
angewendet werden. Dazu kann ein Task- oder Kontext switch 
25 (SWITCH) entspreqhend den Ausftihrungen in PACTll ausgefiihrt 
werden. Die Debuginf ormationen des zu debuggenden Programmes 
werden bei einem SWITCH zusammen mit den relevanten Daten ge- 
sichert 'und das Debugger Programm 'geladen, • das die Inf orma- . 
tionen ausWertet uncj/oder interaktiv mit dem Programmierer 
30 verarbeitet. Danach wird erneut ein SWITCH durchgeftihrt (bei 
welchera die relevanten Inf ormationen des Debuggers gesichert 
werden) und das zu, debuggende Programm wird weitergeftihrt • 
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■ Es sei auch erwahnt, dafi als Debugger ei-n Prozessor-Te[il- 
bereich vorgesehen werden kann. 

Die Debug-Inf ormation wird vorh. Debugger entsprechend Methode 
5 A und/oder B gielesen -und in einen von der Datenverarbeitung 
separaten Speicher und/oder Speicherbereich gespeichert , auf 
.den der DB be.yorzugt. direkten Zugriff besitzt,. Durch das De- 
bugger-Prograinm werden die Breakpoints und {Vor)*Bedi'ngungen 
definiert. Ebenfalls kann das Debugger-Programm die Kontrolle 
10 . iiber die Ausfilhrung der Applikation, insbesondere den Ausfiih- 
rungsstart und das Aus'f lihrungsende aber-nehmen j 

Dfer Debugger stellt dem Prograinmierer eine geeignete Arbeits- 
.umgebung zur Verfiigung mit ggf. graphischer Oberflache. In 

.15 einer besonders bevorzugten Ausftihrung ist der Debugger in 

eine komplexe • Entwicklungsumgebung integriert und tauscht lait 
dieser Daten und/oder Steuerinf ormation aus, Insbesondere 
kann. der Debugger die aus den Arbeitsspeichern gelesenen Da- 
ten zur beliebigen Weiterverarbeitung auf einen Datentrager 

20 (Festplatte, CDROM) speichern und/oder innerhalb eines Netz- 
werkes (wie Ethernet) ablaufen. 

Der erfindjangsgemafie Debugger kann zudem gemaB DE 101 29 
237.6-53 innerhalb einer Entwicklungsumgebung mit anderen 
25 Werkzeugen und insbesondere auch Debuggern kommunizieren; wo-, 
bel in einer .bevorzugten' Ausgestaltung die Steuerung und/oder 
Definition der Debugparameter von einem ander.en Debugger aus 
abernoramen werden kann. Ebehso kann der Debugger die von ihm 
generierte Debug-Inf ormation einem anderen ' Debugger zur Veir- 
30 fiigung stellen und/oder von diesem dessen Debug-Inf ormation 
erhalten. 
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* Insbesondere das Feststellen des.Auf tret ens von Breakpoints 
und/oder (Vor) Bedingung ist durch^einen anderen Debugger bzw.. , 
den Einheiten, die dieser andere Debugger debugt, durchfiihr- 
bar. Der erf indungsgemaBe Debugger und die VPU reagieren dann 
5 . entsprechend. 

Der andere Debugger kann insbesondere der Debugger eines mit 
einer VPU gekoppelten anderen Prozessors (CT, bzw. ARC bei 
Chameleon, Pentium, AMD usw.) sein. 
10 . ' 

^ Insbesondere kann der andere Debugger auf einem der VPU zuge- 
" ordneteri und/oder gekoppelten Pro'zessor ablaufen und/oder. der 
, zugeordnete Prozessor der DB sein, beispielsweise eine . CT • 
bzw. ARC bei Chameleon. In einer besonders bevorzugteh Ausge- 
15 staltung kann der zugeordnete Prozessor ein .Host-Prozessor 
- sein, wie beispielsweise in der 60/317,87 6 und/oder der DE 
102 06 856.9 b.eschrieben. ' 

20 5 . Bewertiang der Methoden 

Die Methode A ist erheblich zeit- Und ressourcenintensiyer 
als die Methode B, bei der kaum zusatzliche Hardware erfor- 
derlich ist und zudem ggf . das zeitaufwendige .Auslesen der 
25. Debug-Information vom Start der. Applikation an entfallt. Da- 
her ist Methode B grundsStzlich vorzuziehen. Fur Compiler . 
nach DE 101 39 170.6 und d^ren Zusatzanimeldungen ist die Me- 
thode' B eiiideutig zu prSferieren. . 

30 Es wurde erkannt, daB insbesondere die Verwendiing beider Me- 
thoden A und B gemeinsam zu den besten und transparentesten ; 
Debuggingergebnissen ftihrt. Insbesondere kann je nach Tiefe 
des zu debuggenden Fehl'ers zunachst unter Zuhilfenahme der 
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schnelien Debuggingmethod'e B debug'gt werden und nach hinrei- 
chende/Lokalisierung des Fehlers sodann per Methode A die De- 
tails in der "Tiefe" analysiert werden. 



6. Mixed Mode Debtaqgey 

Bex der Anweridung der besonders bevorzugten Methode B kann es 
zu dem Problem kommen, dass die in den Speichern befindliche 
10. sichtbare Information nicht hinreichend ist. 

Typischerweise kann ein detaillierteres Debugging folgender- 
iiiassen erfolgen: 

a) Die sichtbare Debuginf ormation (PREINFO) vor der Konf igu- 
. ration einer einen Breakpoint enthaltenden Konf iguration 

15. wird gesichert, Bei Auftreten eines Fehlers bei dem Bre- 

. akpoint wird die dann sichtbar.e Debuginf ormation (POSTIN- 
FO) gesichert. Basierend auf der PREINFO Information wird 
ein Software-Simulator gestartet, der die zu debuggen- 
de (n) Konf iguration (en) simuliert. Der Simulator kann da- 
20 bei jeden Wert innerhalb der PAEs "und der Bussysteme be- 

stimmen und (ggf. auch graphisch ' und/oder textuell) aus- 
geben, wodurchein detaillierter Einblick in den Ablauf 
des' Algorithmus zvim Zeitpunkt des Auftretens des Fehlers 
erreicht wird. Insbesondere ist es moglich, die jeweils 
25 siinulierten Werte mit den Werteh von POSTINFO zu verglei- 

Chen, um Differenzen schnell zu erkennen. 

b) Die sichtbare Debuginf ormation vor einem Breakpoint wird 
gesichert. Bei .Auf tret en eines Breakpoints wird basierend 

30 .auf dieser* Information ein Sof tware-Visualisierer gestar- 

tet. Der zu debuggende Baustein wird niinmehr in einem 
Single-Step Verfahren betrieben, das das Auslesen samtli- 
cher relevanter Daten nach Methode A ermoglicht. Diese 
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Daten .konnen nunmehr entweder direkt Cggf . auch graphisch 
und/oder textuell) ausgegeben warden und/oder an einen • 
Simulator weitergeleitet werden;. dessen Simulation sodann 
auf den detaillierteren Daten beruht, und danach .wis be- 
5 ■ kannt ausgegeben werden. 

6.1 Vor-bexle e±nes Mixed-Mode-Debuggers 

10 Der Mixed-Mode-Debugger ermoglicht die detaillierte Analyse 
k der Ablclufe innerhalb eines Bausteines . Durcri- die Moglichkeit 
^ .gemSB Methode B, bis' zu einem gesetzten Breakpoint mit voller i 
Geschwindigkeit zu arbeiten und danach ggf . . anzuhalten, zu 
verlangsamen und/oder ggf . in einen Single-Step-Modus zu ge- 
15 hen^- wird das . Debugging zeitef f izient,. wodurch das Testen 

grofier Datenmengen und/oder komplexer Algorithmen ermoglicht ' 
wird. Das bevorzugte Aufsetzen eines Simulators nach dem Auf- 
treten des Breakpoints auf Basis der aktuellen Daten und Zu- 
stande ermoglicht einen genauen Einblick. in die Hardware. So- 
20 fern der Zeitaufwand fur die Simulation zu hoch ist und/oder 
die 100% Obereinstimmung des Simulators mit der Hardware 
fraglich ist, ermoglicht das Zurticklesen von Daten im Single- . 
Step-Modus nach Auftreten eines Breakpoints. gemSfS Methode A 
Oder entsprechend des Kontext-Switch Verfahrens nach DE 102 
25 0 6 653.1 und DE 101 39* 170.6 ein 100% korrektes Debugging des 
AlgorithmUs und/oder auch der Hardware selbst. 

7 , Beschreibung der Figuren 

30 

Figur 1 und 2 entsprechen der Patentanmeldung DE 101 39 
170,6. Die unterschiedlichen Ansatze der Methoden A und B 
wurden in die Figuren eingezeichnet (A, B). 



rar/DE 02 / 0 3 2 7 8 



Pigur ib» zeigt eine Reprasentation des endlichen Autoinaten 
durch eine rekonf igurierbare Architektur nach P 44 16, 881.0- - 
53 und DE 196 54 846,2-53 (DE 196 54 846.2-53, Fig, 12-15). 
5 Das kombinatorischen Netz aus Figur la (0101) wird durch eine 
Anordnung von PAEs. 0107 ersetzt (0101b) Das Register (0102) 
wird diirch einen Speicher^ (0102b) ^usgefuhrt, der mehrere Zy- 
klen speichern kann.'Die Riickkopplurig geinaJi 0105 erfolgt 
diirch 0105b. Die Eingange (0103b bzw. 0104b) sind Squivalent 

10 0103 bzw 0104, Der direkte Zugrif f auf 0102b kann ggf- durch 
einen- Bus durch das Array 0101b realisiert werden. Der Aus- 

W gang 0106b ist wi.ederum Equivalent 0106. 

Figur 2 zeigt' die Abbildung eines .endlichen Automaten auf ei- 
15 ne rekonf igurierbare Architektur- 0201 (x) reprasentiereh das 
kombinatorische Netz (das" entsprechend Figur lb als PAE3' aus-. 
gestaltet sein kann) . Es existiert ein oder mehrere Speicher 
fur Operanden (0202) und ein oder mehrere Speicher fur .Ergeb- 
. nisse (0203) . Zusatzlich Daten Ein-/Ausgange gem, 0103b, 
20 0104b, 0106b) sind der Einf achheit haXber nicht dargestellt . 
Den Speichern zugeordnet ist jeweils ein Adressgenerator 
(0204,. 0205) . 

Die Operanden- und Ergebnisspeicher (0202, 0203) sind physi- 
kaiisch oder virtuell derart m'iteinander verkoppelt, daB bei- 
25 spielsweise die Ergebisse einer Funktio,n einer anderen als 

Operanden dienen kSnnen und/oder Ergebnisse und Operanden el- 
• ner Funktion einer ■ anderen als Operanden dienen kSnnen. Eine 
derartige Kopplung kann belspielsweise durch Bussysteme her- 
gestellt werden oder durch eine (Re) Konf iguration, durch wel- 
30 che die Funktion und Vernetzung der Speicher mit den 0^01 neu 
konfiguriert wird, * • ' 



mVDE 02/03278 



Figiir 3 zeigt eine mttgliche schematische Struktur des Debug- 
gings nach Methode' B . Es sei insbesondere beispielhaift auf 
. die Figuren 19, 20, 21'.der Patentanmeldung DE.199 26 538.0 

verwiesen, in welcher die Grundlage der Speicher beschrieben 
5 ist. . Die DE 1.99 2 6 538.0 wird hierntit zu Of f ehbarungszwecken. 
vollumf anglich eingegliedert . ' ■ 

OlOib und 0102b ist. wie bereits besphrieben dargestellt . ■ Zu- 
satzlich ist eine externer Speichereinheit dargestellt 
10 (0302), der moglicherweise Shnlich DE 199 26 538.0 an 0102b 
angeschlossen (0307) sein kann. Es soli besonders darauf hin- 
gewiesen werden, dafi sowohl. 6 102b als auch 03G2 externe bder 
interne . Speichereinheiten sein konnen. Ebenfalls soil eine 
' Speichereinheit als mindestes ein Register, eine Menge von 
15 Registern oder ein Speicher (RAM, Flash, o-S,) oder.Massen- 
speicher (Festplatte, Band,, o.a.) definiert sein. 

Die debuggende Einheit 0301 kann Breakpoints innerhalb 0101b 
setzen (0303) , auf Basis derer der eigentliche Debug Vorgang 
20 ausgelost wird. Durch das Erreichen eines Breakpoints wird 
eine Information (0304) an 0301 gesendet, die den Debug Vor- 
gang startet; zugleich werden auch alle 0101b interenen Vor- 
kehrungen zum Debuggen (z.B^ ein Anhalten und/oder Verlangsa- 
men des Taktes) ausgelost • Alternativ kann aucti durch 030.1 
25 . die Information generiert und an 0101b gesendet werden. 

. Ober 0305 und/oder 0306' kann 0301 auf die Daten und/oder Zu- 
stande aus de'm Speicher 0i02b und/oder dem Speicher . 0302 zu- 
greifen. Der Zugriff karin zum Beispiel 

1. durch eine Speicherkopplung (Block-Move, d.h. kopieren 
30 • der Speicher in einen anderen, von 0301 kontrollierten 

Bereich) , 
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2. durch eine Leitung (serielle oder* parallels Leitung, 
aber die ein oder mehrere Speicherbereich (e) . ubertragen 
wird/werden, z.B. JTAG) , 

3. Buskopplungen gleich welcher Art (die Speicher werden 

. .5 ahnlich eines DMA'-Veff ahren arbitriert und von 0301 ver- 

arbeitet) • * " ' \ ■ ' ' 

erf olgen. ^ . - / * . 

y • Als Beispiel' wurde eine Figur aus der DE 199 26 538.0 ge- " 
10 wahlt . Es soli ausdriicklich darauf hingewiesen. werden, dali 

•grundlegend jedes Speicherverf ahreh und jede Speicherkopplung 
(Stack/ • Random-Access, FIFO, usw.) entsprechend bearbeitet 

werden kann, . - 

• ' ' »' ' - 

15 Die .Figuren 4a und 4b zeigen weitere ni5glichen Ausgestaltun- 
gen und wurden aus der Patentanmeldung DE 102 06 856.9 ent- 
. ' nommen, die zu Of f enbarungszwecken * vollumf anglich eingeglie- 

. * ■ . dert ist • . 

20 Der Aufbau einer besonders bpvorzugten" VPU ist in Figur 4a 

dargestellt. Vorzugsweise hierarchische Konf igurationsmanager 
(CT's) (04 01) steuern und verwalten eine Anordnung von rekon- - 
f igurierbaren Elementen (PACs) (04.02) . Den CT's ist ein loka- 
ler Speicher fur die Konf igurationen zugeordnet (0403) . Der 
25 Speicher verfiigt weiterhin iiber ein Interface (0404) zu einem 
globalen Speicher, der die Konf igurationsdaten zur Verfugung 
stellt; Uber ein Interface (0405) sind die Konf iguratibnsab- 
lauft steuerbar. Ein Interface der rekonf igurierbaren Elemen- 
te (0402) zur Ablauf steuerung und Ereignisverwaltung (0406) 
30 ist vorhanden, ebenso* ein Interface ziom Datenaustausch 
(0407). Beipielsweise kann eine der CT's als DB agieren. 
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Figur 4b zeigt einen Ausschnitt aus einem beispieihaf ten CPU- 
■ System^ beispielsweise einem DSP des Types C6000 von Texas 
Instruments' (0451.). Dargestellt sind Prograitmspeicher (0452), 
Datenspeicher (0453) , beliebige Peripherie (0454) und EMIF 
.5 (0455). Ober einen Speicherbus (0456) und einen Peripheriebus 
(0457) ist eine VPU als Coprozessor integriert (0458). Ein* 
DMA- Ko.nt roller (EDMA) (045 9) kann beliebige DMA-transfers, 
beispielsweise zwischen Speicher • (0453) und VPU (0458) oder . 
Speicher (045-3)' und Peripherie (0454) durchftihren. In diesem 
10 Beispiel kann 0451 als DB arbeite'n und insbesondere auch der . 
erf indungsgemaUe Debugger mit dessen Debugger gekoppelt. 
lind/oder in diesen integriert sein. 

Figur 5a zeigt einen beispieihaf ten Hardwareaufbau, der zum. 
15 Debuggen von fekonf igurierbaren Prozessoren benutzt werden 
kann. Hierzu wird ein gepipelinter Konf igurationsbus ' 0501 
verwendet, ahnlich dem aus DE 100 28 '397.7 bekannten. Die 
Pipeline ist .uber mehrere Registerstuf en (0502) in horizonta- 
ler und/oder vertikaler Richtung aufgebaut, uiti h6here Takt- ■ 
20 frequenzen zu erreichen. Der gepipelihte Konf igurationsbus 
- flihrt zu den zu konf igurierenden Elementen .(PAEs) (0503), urn 
diese mit Konf igurationsdaten zu. versorgen. 

Pigur 5b zeigt beispielhaft die erf orderliche Erweiterung ge- 
.25 mafi dep vorliegenden Erf indung. .Jede Register stufe (0502) de- 
krementiert den Zahlenwert (LATVAL) zum Ausgleich der Latenz- 
zeit um 1 (angedeutet durch -1) - Ebenso dekrementiert jede . 
PAE (0503), die bereits eine Taktsteuerinformation erhalten 
hat, diese pro Takt um 1 (angedeutet durch -1/T) . Auf die 
30 PAEs und insbesondere de.ren internen Register kann nunmehr 

nicht nur schreibend, sohdern auch lesend zugegriffen werden, 
z.B. uber- eine besbndere Steuerleitung (RD) , um Debugdaten • 
auszulesen. Zu • schreibende und gelesene Daten durchlaufen in 
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diesem Beispiel das Bussystem durch das Array aus* PAEs von 
links n^'ch rechts und in der untersten Zeile in Ruck- 
wart srichtiing. Der Konf igurationsbus ist weiterhin uber Regi-- 
sterstufen (0505) pipelineartig zuriickgef iihrt , (0504) . In die- 
sem Beispiel kann eine ubergeordnete Einheit (CT/Ladelogik, 
Hostprozessor) (0506) ebenso lesend und schreibend auf den 
Bus zugreifen, wie ein dediziertes Testinterf ace (0507) . Das 
Testinterface kann einen eigenen Test kontroller . auf weisen und 
insbesondere kompatibel zu einem oder mehrern marktgangigen 
Testschnittstellen seiri (z.B, JTAG, Tektronix, Rhode &Schwarz, 
etc) . Die Auswahl der bussteuernden Einheit effolgt Uber eine 
Multiplexer/Demultiplexer-Einheit (0508) . In (0509 ,in klam- 
mern urid kursiv dargestellt) oder vor den Einheiten 0506 und 
0507 kann eine Schaltung zur Ruckrechung der Herkunf tsadresse 
(0509) von Debugdaten, die nber 0504 eintreffen, vorgesehen 
sein. Die Adressberechniingen innerhalb des aufgezeigten Sy- 
stems geschehen wie folgt: Zunachst wird die Adresse durch 

0506 Oder 0S07 am Bus 0501 * angelegt . Die Adresse wird ahniich 
der Verarbeitung der Zahlenwerte (LATVAL) zur Latenzberech- 
nung in jeder Registerstuf e (0502 und 0505) dekrementiert . 
Sobald die Adresse gleich 0 ist, wird 'die ,nach. der Register- 
stuf e liegende PAE selektiert. In der- nachfolgenden Register- 
stufe wird die Adresse negativ, so dafi keine weiteren PAEs 
mehr aktiviert werderx. Sofern Daten aus einer PAE gelesen 
werden, werden diese zusammen mit der Adresse zurtickabertra- 
gen. Die Adresse wird dabei in jeder Registerstufe weiter de- 
krementiert. Eine RUckrechnung in 0509 der bei 0506 und/oder 

0507 zu'sammen mit den Debugdaten eintref f enden Adressen ist 
nunmehr durch eine einfache Addition mdglich, indem die An- 
zahl der dekrementierenden Registerstufen zu dem eintreffen- 

den Adresswert hinzuaddiert werden. Es soil angemerkt . sein, ^ 
dass die Registerstufen 0502 in Figur 5b leicht unterschied- 
lich gegenUber den Registerstufen 0502 in Figur 5a ausgestai- 
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tet sind. In Figur 5b weisen • diese nkmlich zusatzlich eine 
Schaitung. (z.B. Multiplexer) zu Auswahlder weiterzuleitenden 
Daten auf / der entweder die Daten des Busses 0501 weiter- 
schaltef Oder den Ausgang der zugeordneten PAE (0503). und .so- 
5 mit die DebugDaten. Zur Ansteuerung der Schaitung kann das ^ 
Auftreffen des Adresswertes gleich 0' dienen. 

Es wird nochmals darauf hingewiesen, ■ daJi das' dedizie.rte Te- 
stinterface (0507) den Industriestandards entspricht. Es kann 
10 zu Tests wShrend des Sof tware-Debug-Vorgan^s eingesetzt wer- 
^ den und/oder zu Test wShrend des Zusammenbaus von Hardware- 
PF kofappnenten und -systemen • (z . B. dem Zusairahenbau der Schaltun- 
gen auf der Platine) .und/oder zu Funktionstests des Halblei- 
terbausteins (Chips)' im Rahnieh' der Halbleiterf ertigung. Ins- 
;15 besondere dadurch kann die flbliche Scan-Chain zum Test der 

Register w^hrend des Funktionstests des Halbleiters entfallen 
Oder zumindest eritsprechend 'minimiert werden, da dann nur die 
■ Register durch die Scan-Chain gefilhrt werden mussen, die 
nicht vom- Bus system (0501) ansteuerbar sind. » ' * • 

20 ' ; . . ^ ^ 

Ebenf alls wird besonders darauf hingewiesen, dafi das . in Figur 

^* 5 erlauterte Verfahren. keinesfalls. auf die Anwendung bei .Kon- ^ . 

^ f igurationsbussen beschrankt ist. Gewohnliche Datenbussysteme 
konnen ebenso zu den ' unterschiedlichen vorab aufgezahlten 

25 Test- und Debugging-Zeitpunkten und -arten verwendet werden. 
•Insbesondere sei in .diesem Zu'saininenhang auf das in der DE 197 
04 742.4 beschriebene Datenbussystem hingewiesen. Die DE 197 
04 742,4 ist hierzu zu Of f enbarungszwecken vollumf anglich 
eingegliedert. Die in Figur 5 beschriebenen Verfahren konnen, 

30 fUr eirien Ingenieur mit gewohnlichen technischen Kenntnissen 
leicht nachvollziehbar ebenso auf die DE 197 04 74'2.'4 ange- 
wendet werden. 
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Ein Mischbetrieb unterschiedlicher Bussysteme, .wie Konfigura- 
tionsbussystemen, Datenbussystemen nach DE 1197 04 742.4 und' 
gewohnlichen Datenbussystemen ist desweiteren. grundsatzlich 
moglich. Dazu konnen mehrere Testinterf ace vorgesehen sein, 
Oder wie technisch bevorzugt die Multiple- 

xer/Demultiplexerstuf e (0508) auf eine Mehrzahl .von Bussyste- • 
men (n x.0501, n x 0504) ausgelegt werden. * 

. * • * ' ■ » 

Abschliefiend soil noch bes.onders erwahrit. sein, dass diirch die 
Rtickfuhrung de^s Bussystems nach'Figur 5b auch die in die PAEs 
zu schreibenden Konf igurationsdaten zuruckgef uhrt werden. On- 
ter Zuhilfenahme d^r Adressriickrechung (050.9) und der zurtick- 
gefiihrten Statusleitung REJ, die nach DE 100 28 397.7, DE i98 
07 872-2, DE 196 54 593.5-53 eine ZurUCkwei sung der Konfigu- 
■rationsdaten anzeigt/ kann auf die Verwendung der Konfigura- 
tionszwischenspeicher-FIFOs nach DE 100 28 397.7 Figuren 8 
und 9 (0805, 0903) verzichtet werden, da deren Funktionalitat 
nunmehr vollumf anglich iiber das beschriebene Bussystem* abgie- 
bildet wird. 
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8 : Begriff sdef inxtlon 
lokal relevaniier Zus-band 
• . 5 ■ 

global relevanter Zus-band. 

10 

^ ■ 

^^^^ relevanter Zus-band . 

15 

irrelevan-ber Zustand . 

20 
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Zustand, der nur innerhalb einer 
bestimmten Konf igurat,ion relevant 
' ist:. . \ • 

Zustand/ der in mehreren Kohfigu- 
rationen relevant ist uhd zwi- 
schen den Konf igurationen ausge- 
tauscht vrerden mufi. 

Zustand, der innerhalb eines Al- 
gorithmus zur korrekten Ausfiih- 
rung dessen benOtigt wird und so- 
mit durch den Algorithmus be- 
schrieben ist und verwendet wird, 

Zust'and, der fiir den eigentlichen 
Algorithmus ohne Bedeutung ist 
und au'ch nicht im Algorithmus be- " 
schrieben ist, der jedoch von der 
ausfiihrenden' Hardware implemen- 
. tierungsabhangig benotigt wird. 
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Titei: ' Verfahren zum Debuggen rekonf iguriierbarer . 
Architekturen 

Patentansprtiche 

1. Verfahren zum Debuggen von rekonf igurierbarer Hardware; 
dadurch gekennzeichnet^. daJB samtliche notwe^dige Debug- 
information je Konfigurationszyklus in einen Speicher ge- 

' • schrieben werdeh, der dann vom Debugger ausgewertet wird. 

2. Verfahren nach dem vorhergehenden Anspruch, dadurch ge- • 
. kennzeichnet, dali wahrend des Debug- Vorganges nach Auf- 

treten einer Debug-Bedingung, gemSB welcher Information 
(iber die zu debuggende Konf iguration benc3tigt wird, eine 
Konf iguration geladen wird, mittels welcher die in den 
Speicher geschriebenen Debug-Inf ormationen ausgelesen und 
insbesondere in eine ' Debug-Einheit Oder Debug-Konf igura- 
tion geschrieben werden. 

3. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekenn'zeichnet , dali eine zu debuggende Konf igurati- 
pn vor dem Ablauf des DelDugging derart .verandert wird, 
dafi bei ndrmaler, nicht-debuggender Ausfiihrung nicht er~ 
forderliche Information in einem Speicher abgelegt wird. 

4. Verfahren nach einem der vorhergehenden AnsprOche, * da- 
durch gekennzeichnet, dafi. zum' Auslesen die Taktfrequenz 

zumindest verlangsamt oder angehalten wird .und/oder eine 

I ► • , 

taktweise Abarbeitiing der zu debuggenden Konf iguration 
Schritt far Schritt erfolgt. 
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Verfahren nach einem der vorhergehenden Ansprtiche, da- . ' - 
durch gekennzeichnet^ daB die zu debuggende. Konf iguration 
nach Auslesen der relevanten Information- oder nach davor- 
liegender Information simuliert wird. 

Vorrichtung mit einem Feld konf igurierbarer Elemente, • 
insbe'sondere grobgfanularer logischer lind/dder arithmeti- 
scher Einheiten 'sowie einem Debug-Mittel ziom Debuggen von* 
Programmen, Programmteilen oder auf dem Array auszuftah- 
renden komplexen Opefationen, dadurch gekennzeichnet, daB 
das Debug-Mittel ein Speichermittel zur SpeicHerung von 
fur das Debugging relevanten Inf ormatiohen wShrend oder 
am Ende eines Arbeitisschrittes des Feldes konf igurierba- 
rer. Elemente umfafit, wobei da^ Speichermittel zum Debug- 
ging auslesbar ist- 

Vorrichtung nach dem vorhergehenden Anspruch, dadurch ge- 
kennzeichnet, dali das. Speichermittel als Duail-Ported-RAM 
mit einem ersten Eingarig ftir" abzuspeichernde Information 
aus dem Prozessorf eld und einem zweiten Eihgang zum Aus- 
lesen der Information in ein Analysemittel ausgebildet 
ist. * ' • ■ ^ 
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Titel: . \ Verfahren zuiti Debugger! rekonf igurierbarer 
Architekturen 

5 Zusammenf assung 

Die Erfindung betrif ft ein .Verfahren zxim Debugger! von rekon- 
figurierbare;r Hardware. Hierbei ist ii. a. vorgesehen^ daB 
10 samtliche notwendige Debug.-Inf ormation je Konf igurationszy- 
klus in einen Speicher geschriefben wird/ der dann.vom Debug- 
ger ausgewertet wird. 



15 

(Fig, lb) 



20 
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